Communications technologies and uses have greatly changed over the last few decades. In the fairly recent past, copper wire technologies were the primary mechanism used for transmitting voice communications over long distances. As computers were introduced, the desire to exchange data between remote sites became desirable for many purposes such as those of businesses, individual users and educational institutions. The introduction of cable television provided additional options for increasing communications and data delivery from businesses to the public. As technology continued to move forward, digital subscriber line (DSL) transmission equipment was introduced which allowed for faster data transmissions over the existing copper phone wire infrastructure. Additionally, two way exchanges of information over the cable infrastructure became available to businesses and the public. These advances have promoted growth in service options available for users.
As the consumer electronics industry continues to mature, and the capabilities of processors increase, more devices have become available for public use that allow for the transfer of data between devices and more classes have become available that operate based on this transferred data. Of particular note are the Internet and local area networks (LANs). These two innovations allow multiple users and multiple devices to communicate and exchange data between different devices and device types. Regarding the Internet, its physical structure and associated communication streams have also evolved to handle an increased flow of data. Servers have more memory than ever before, communications links exist that have a higher bandwidth than in the past, processors are faster and more capable and protocols exist to take advantage of these elements. As consumers' usage of the Internet grows, service companies have turned to the Internet (and other Internet Protocol (IP) networks) as a mechanism for providing traditional services. These multimedia services include Internet Protocol television (IPTV, referring to systems or services that deliver television programs over a network using IP data packets), video on demand (VOD), voice over IP (VoIP), and other web related services received singly or bundled together. Similar comments apply to cellular networks which can also handle communications with devices through the Internet or other connected networks.
To accommodate the new and different ways in which IP networks are being used to provide various services, new network architectures are being developed and standardized. One such development is the Internet Protocol Multimedia Subsytem (IMS). IMS is an architectural framework for delivering IP multimedia services, such as IPTV, to an end user. The IMS architecture used in an IMS system 10 can be broken down into three layers, as shown in FIG. 1: (1) a service layer 12; (2) a control layer 14; and (3) a connectivity layer 16. The service layer 12 includes class servers (ASs) 18, 20 which contain services and applications that can be delivered to an end user, e.g., IPTV services. The control layer 14 includes a home subscriber server (HSS) 22, a media resource function (MRF) 24, a call service control function (CSCF) 26, a signaling gateway/media gateway control function (SG/MGCF) 28 and a media gateway 30. These elements in the control layer 14 are typically used for managing session set-up, resource modification and release of resources. The connectivity layer 16 includes routers and switches used in both the backbone network and the access network. These elements are shown in FIG. 1 by Internet Protocol (IP)/multi-protocol label switching (MPLS) 32, the public switched telephone network (PSTN)/public land mobile network (PLMN) 34 and media gateway 30. This connectivity layer 16 is used to connect various end user devices to either each other or a variety of services and applications. Some types of end user devices are, for example, personal computers and mobile phones. It will be appreciated by those skilled in the art that more or fewer elements can exist in an IMS architecture.
Session Initiation Protocol (SIP) signaling is often used for setting up, modifying and terminating sessions between two devices. For example SIP signaling could be used between mobile devices to set up a session or used between a mobile device and an application server associated with IMS for receiving a multimedia service on the mobile device. As interest in IMS grows, the quantity of IMS enabled applications being developed for end user devices, e.g., mobile phones, is increasing. This, in turn, leads to the desire to create efficient SIP addressing methods. Currently, an incoming SIP request to access an application available in a mobile terminal is routed in that mobile terminal to a certain application class depending on the parameters, e.g., SIP headers and parameters, used in the incoming SIP request.
For example, a current method for handling initial SIP application requests received by a mobile device will now be described with respect to FIG. 2. FIG. 2 shows a mobile device 200 in communications with an IMS network 202 and an external entity 204. External entity 204 can be a network entity such as a login entity or an authentication server or the like. Mobile device 200 includes a SIP support layer 206, an application dispatcher 208, a number of deployed applications 210 and an application dispatching manager (ADM) 212. Initially, a SIP application request is received by mobile device 200 from the IMS network 202 at the SIP support layer 206. The SIP support layer 206 forwards the SIP request to the application dispatcher 208. The application dispatcher 208 sends the SIP request to the ADM 212. The ADM 212 then reviews the SIP request and attempts to make a decision regarding which application class is to be the handler for the incoming SIP request. The ADM 212 makes this decision based upon a variety of factors, such as, the request parameters, security aspects and terminal capabilities. If the ADM 212 is unable to decide which application class is to be the handler for the incoming SIP request, the ADM 212 can send a request to an external entity 204 for guidance. If the ADM 212 is able to make the determination itself, then the SIP request is sent back to the application dispatcher 208 for appropriate dispatching. This process may include an authentication procedure or a request to an external entity 204 which can be both time and resource consuming.
After this initial application request processing between the two mobile clients, it may be desirable for subsequent SIP application request processing between these two clients to reflect the knowledge acquired during the initial handshaking. For example, after dialog establishment, the mobile clients involved in the communication may be aware of which application classes, e.g., available application classes such as chess and VoIP, are being used on both mobile devices associated with the SIP request. One of the mobile clients may then, for example, want to address the same class by, e.g., sending a SIP MESSAGE outside of the current SIP dialog. Alternatively, one mobile client may choose to end and then re-establish the dialog between with that other mobile client using the same class that was used before. In at least these cases, there should be no need to perform the time and resource consuming routing procedure described above for choosing the application class to use, since the same class should be used as was used during the previous dialog between these two mobile entities.
However, there is currently no mechanism in place that allows mobile clients to avoid the long dispatching procedure when wishing to repeat a session using the same class between two devices. Accordingly exemplary embodiments described below address the need for improving the efficiency of routing for application requests in devices, e.g., mobile devices.